Subject: Flow Control Rats and Mice

From: "Shannon Nix" <[email-masked]>
Date: Tue, 13 Dec 94 11:04:05

Date: Tue, 13 Dec 94 07:49:45 PST
From: [email-masked]
Sender: [email-masked]
Subject: RE: Returned mail 
To: [email-masked], [email-masked]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

Hi Alan,

Here it is, finally..

Best regards, Shannon

>As editor I feel that all groups should come to conclusion on
>what is and isn't important for CP status.  This should drive
>the decision more than the schedule.  I do have some edits from
>Steve Klein, Gene Cox is going to get back to me on a Priority issue.
>
>As far as your contribution is concerned, it would be appreciated
>by this weekend (I just love doing this on weekends ;-)      ).
>But if there are any issues to be discussed with the working
>group, I would submit it first to the group with a 1 week deadline
>on comments (which would mean not posting the CP document until
>after Thanksgiving).  If you need to work with the group, post the
>changes to the group and to me directly.  I will go ahead and
>edit it in assuming there will not be a lot of changes from the
>group.
>
>Regards,
>
>Alan.
>
>
>--- Begin Included Message ---
>
>Date: Tue, 15 Nov 94 11:23:13 
>From: "Shannon Nix" <[email-masked]>
>Encoding: 4605 Text
>Message-Id: <[email-masked]>
>To: [email-masked]
>Cc: [email-masked], 
>networking.cary.ibm.com!aiw-dlsw-flowcontrol@u
>unet.UUCP
>Subject: 015 comments
>Content-Length:       4507
>Status:   
>
>
>          Hi Alan,
>          
>          Just so you know...I owe you something for CP.
>          
>          Attached is a list of issues that need some resolution before
>          CP.  There's nothing contentious in here...I just need to find a 
>          few cycles.
>          
>          Let me know what your time requirements are.
>          
>          Rgds, Shannon
>          
>          Some comments/instructions below.
>
>
>______________________________ Forward Header __________________________________
>Subject: 015 comments
>Author:  "Peter W. Gayek" <[email-masked]> at Internet-Gateway
>Date:    11/7/94 2:24 PM
>
>
>Shannon,
>In reviewing 015 for AP status and also David McDonell's post, a few
>flow control issues came up.  Please feed what you feel is the proper
>resolution of these to Alan so they can be in our CP document.
>
>- There are still two lists of which SSP msgs can carry grants, in
>  sections 8.2 and 8.6.  I am sure we decided to get rid of one of
>  them, but I can't remember which one.  Whichever it was, we should
>  be sure it reflects the decision we made about RESTART_DL and
>  DL_RESTARTED.
>
>SDN>  Yes you're right.  We actually made the change "in real time"
>      but I guess this got lost.

Here it is again.  8.6 should now read:

...or the FCIND may be piggy-backed on any of the message types listed in
section 8.2 of this chapter.

<delete list>

>
>- I don't have good notes for the flow control discussion at AIW6, but
>  it seems someone should make sure any other decisions we made there
>  all got recorded in the text.  (when the one issue I do remember
>  isn't there, I get nervous about any others)
>
>SDN> The know of no other issues other than the ones you have touched on in
>     this memo.
>
>- Section 8.3.5 - I think this editor's note can be removed;  what we
>  have on the Halve Window Operator is adequate.
>
>SDN> I need to review this (as I don't have the text on hand at the moment)

Remove it.  (I believe you have already)

>
>- The three reset window flows you posted all ended with a sequence
>  like the following:
>     0         0   IFCACK------------->   0         0
>                                          Condition eases
>     1         1   <-------- FCIND(Inc)   1         1
>     0         1   FCACK-------------->   1         0
>     2         2   <-------- FCIND(Inc)   2         2
>     1         2   DATA--------------->   3         4
>  I think the very last frame in each flow should be "FCACK" rather
>  than "DATA", unless you show the preceding FCIND crossing it.
>
>SDN>  -- oops! ..a protocol violation.

Section 8.8.3 has three example flows.  The last line of each flow should have the
text "DATA-" replaced with "FCACK".
>
>- David McDonell posted the following flow control comment:
>
>> - section 8.1 (basic overview, flow control, p.68): I feel there's a little
>> ambiguity here around flow control of a DLSw *circuit* vs. that of the
>> switch-to-switch pipe (*connection*).  Maybe a concise definition of the
>> term "session" as used here (and in 8.6 et al) would be a good way of
>> making that clear, along with some stmt referring to "unique instances" of
>> the pacing machine(s) implemented for each connection/session.  The confusion
>> is furthered by the fact that the initial window size in the CapEx is sent at
>> connection establishment, but applies to all subsequent circuits (er,
>> sessions)....(!).  (Legal to draw a parallel with adaptive/fixed session
>> level pacing in SNA, vs. T2.1 adaptive bind pacing?  I didn't think so...)
>
>  I would like to see a global replace of "session" with "circuit" in
>  the flow control section.  "Session" is not defined here or elsewhere
>  in the document - why define it to mean "circuit" when we can just
>  use the word "circuit" instead?  Also, this would eliminate any
>  confusion with the concept of a SNA session.
>
>SDN> - I agree with this global replace.  I haven't taken the cycles
>       to read through and see if it "reads alright" though.
>

I've read it and still agree that any usage of session should be replaced with circuit.

>  I disagree with David that there is ambiguity about circuit versus
>  transport connection in the use of initial pacing windows, etc..
>  I think the text in sections 8.1 and 8.6 is abundantly clear about
>  how the IPW is exchanged on a TC basis but applied to circuits
>  as they come up.
>  A better parallel (but one I do not feel is necessary to add) would
>  be session level pacing running on top of a DLC's RR/RNR flow
>  control mechanism.  BIND pacing is a pipe-level instance of the
>  session-level mechanism, while what we have with TCP is a completely
>  different flow control mechanism at the pipe-level.

I agree with Peter here (no change recommended)

>
>- By the way, you may also want to tell Alan to change the few
>  occurrences of "discreet" to "discrete".  The two words have
>  different meanings, and we want the latter.
>
>SDN>  ....ok..so I can't spell.  Let's be discreet about it.
>

Replace my poor spellin'.

>Peter
>
>Shannon
>    
>--- End Included Message ---